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SECURE ARCHITECTURE FOR EXCHANGE EXECUTES DIGITALLY SIGNED 

CONTRACTS 



Robert M. Green, Jeremy M. Stammers, Vincent A. Cate, 

Sean Hastings 



CROSS-REFERENCE TO RELATED APPLICATIONS 



This application claims the benefit of U.S. Provisional 
Application No. 60/107 , 261 , filed on November 5, .1998 and 
entitled w SECURE ARCHITECTURE FOR EXCHANGE EXECUTES 
15 DIGITALLY SIGNED CONTRACTS". In addition, this application 
claims the benefit of the filing date of U.S. Application 
09/292,291, filed on April 15, 1999 with the same title. 
Both applications are herein incorporated by reference. 

BACKGROUND OF THE INVENTION 

2 0 1. Field of the Invention 

This invention relates to the use of. computers, 
networks, and encryption algorithms to manage and secure 
exchanges of value, .and more particularly, to . a ■ computer 
architecture and system for performing and managing value 
25 exchanges that operate on a wide range of inexpensive 
computer systems. 



1 
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2. De scription of the Prior Art 

Until the early 1950s, transactions to exchange value, 
such as invoicing, payments, wire transfers , market trades, 
conversions from one value unit to another, were handled 
manually by specialized paperwork and human processing. This 
manual processing was slow and error prone: As computers 
were applied to these activities, specific computer systems 
automated particular types of value transactions , ■ usually 
book entry systems . Of ten the manual processes were copied 
as is into computer form and automated with the same 
restrictions, assumptions, and context as the manual 
process . 

With the invention of encryption, especially public key 
encryption, some value transactions were made more secure : 
from intrusion and interference. However, these prior 
computer systems, protocols, and architectures have the 
following disadvantages: 

• they are specialized for certain transactions only and 
.often for certain geographic areas only; 

• some require specialized hardware, such as Smart Cards; 

• some require private communications networks and will 
not work on public networks, such as SWIFT; 

• some require continuous, two way communication to 
validate and record transactions; 

• some are closed to new entrants (i.e., they, work only 
with existing organizations, such as' protocols for ' 
authorizing credit and debit cards/which only work 
with banks; the architectures have elements. of the 
existing organizations and businesses built into them; " 
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• some are closed systems which do not lend, themselves to 
integration into customized .applications ; 

• they are not secure (i.e., they do not use strong 
encryption) ; 

they cannot handle multiple accounting units in the 
same transactions; 

• they -assume a hierarchical, asymmetrical relationship 
between parties in a value exchange (that is, someone 

is always the bank and who cannot also- be the merchant . 
or customer in the same transaction) ; in computer 
system terms, they distinguish strongly between the 
client and server -a party is either one or the other 
but not both; 

• they are explicitly based on a specific regulatory 
commissions and limited to that commissions' view of 
value transactions. 

• they can only handle an arbitrarily small number of 
parties in one transaction, often only three or four 
(one customer, one merchant, one bank- and one credit 
card organization) ; 

• they are inherently structured to be used in a limited 
number of legal jurisdictions; . 

• they can only function on-line, and have no ability to 
. complete an exchange off-line; 

• they assume a fixed degree of trust between parties, 
often specified by an organization at the top of a 

• hierarchy that created the protocol; if you do not 
accept your place in the hierarchy and their rules on 
how much to trust parties, you cannot use the protocol;. 
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• some, such as- the ANSI- EDI standards, are document 
presentation protocols, without digital signatures, 
non- repudiation and bookkeeping. 

"Value exchanges" in the abstract sense are a part of 
payments, invoicing, , bartering, market making, wire 
transfers, stock trades, issuance, and clearing of checks, 
and currency conversions. The existing prior art performs . 
some, but not all of these value exchanges, or only performs 
the. communication needed prior to the exchange and not the 
exchange itself. 

Other Efforts: There are three basic approaches to 
electronic payments and /or value exchanges: software-coin 
based, account-based (there are banks who know who the money 
belongs , to - the present invention falls in this, category) , 
secure-hardware based (Mondex- the money is : contained in the 
card) . 

• Software-coin approach 

• eCash (tm) from Digi.cash. 

• Account approach 

• Credit Card Based Systems 

• Netscape's SSL Protocol for transmitting your 

• ■ credit card . 

•• First Virtual allows you to authorize use of 
■' your credit card without giving out the ^ 
actual card number. 

• CyberCash(tm) . Aftsrhpc a public key to a ' 
credit card. 
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• SET - Secure Electronic Transaction from 
MasterCard, Visa, American . Express etc 

• Other Systems: 

5 • Open Trading Protocol is a method of making 

incompatible payment - systems interoperable. . 
It sits on top of .other payment systems such 
as Mondex and is supported by a consortium of 
payment vendors . 
10. •• Open Financial Exchange is a standard for 

formatting requests and responses in a markup 
language, but does not specify how the 
requests are processed; security via SSL is 
* optional; 

15 • JEPI - Joint Electronic Payment Initiative 

from CommerceNet and W3C (the World Wide Web . 
-Consortium) 

• The SAXAS™ System (the invention described herein) 
• Secure-Hardware approach 

2 0 .. ATM Systems. 

• Smart Cards . 

• Mondex Electronic Cash. Embeds the money and . the 
" . secret that protects it in a special smart card. 

• E-Check - Electronic Checkbook on a smart card 
25' from the US based Financial Services Technology 

Consortium and FSTC members; Federal Reserve Bank, 
NationsBank, Bank of Boston, Huntington 
. Bancshares, IBM and Sun Microsystems and others. 

• EMV - Debit/credit cards using chip technology 

3 0 from Europay, MasterCard and Visa. 
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A number of these efforts are worth describing in more 
detail, in order to create a comparison between them and the 
present invention, the SAXAS system'. 
5 . • 

Mondex Electronic Cash extends the ATM model by making ' 
smart cards where the money and the secret that protects it 
are embedded in a special card. .The security of the money is 
dependent upon special hardware that is difficult to break 
10 into. To spend the money., you must, insert the card into an. 
ATM or special reader. If you cannot read the internals of 
the card, you cannot duplicate it. If you could duplicate 
■ the card, you could steal the "money" . The money belongs to 
the physical card; if you lose the card, you lose the 
15 money. If someone steals the card, they may not be able to 
. spend the money, if the card has a PIN, but you have still 
lost it. There is no output from the card except to a card 
reader such as the ATM. If a phony ATM on the street was 
taking all your electronic money, but telling you it was. 
20 not, you would have no way of knowing until you tried to use 
the card again later at a real ATM. Mondex will probably be 
used mainly for small amounts,- with.no accounting record . . 

This model of. electronic money is patterned after real 
25 physical money. The value is recorded in a unique physical 
configuration that, is difficult to counterfeit and can be 
used anonymously. 

CyberCash, on the other hand, puts a public key around 
30 an existing credit card number in order to allow merchants 
to do real-time. credit card authorizations. CyberCash is 
converting its system to use SET, which is a version of this 

6 
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approach created by the credit card organizations 
' themselves . 

The present invention, the SAXAS system, can easily 
5' emulate the wrapping of a credit . card in a public key: in 
the agreement field of a SAXAS contract, you authorize 
another party to charge your credit card, and then you 
digitally sign the contract. But SAXAS can do much more: 
handle multiple accounting units, match up complementary 
0 conversion orders, and transfer values without a credit card 
being involved. 

eCash™, a product of Digicash, offers software-based . 
electronic coins that can be spent at eCash merchants and. 
5 verified at a central point or' bank. Since eCash. "coins " can 
be digitally duplicated, the first person to the bank gets 
the money.. They can only be used . once and each has a unique 
serial number. There is no special hardware required, since 
each coin is just a string of bits that equals the right to 
0 a specific amount of money. . 

eCash assumes a central issuing authority, modeled 
after existing currency issued. by governments and deposited 
•at banks. When you transfer eCash to another party , the bank 

5 must play a part . That is because eCash coins can be 

duplicated and can only be spent once.- Therefore, .eCash must 
have a central database that lists all the serial numbers of 
coins issued and which have been spent so far. SAXAS allows 
accounting unit balances to move from party to party without 

0 the issuing bank being aware of the transfer. ECash uses a 
Blind Signature and cannot trace its own cash. 

• 7 . 
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The SAXAS system can emulate the eCash capability by 
creating a one- time" identity for a SAXAS contract, then 
including the private key as well as the public key within 
the contract. Anyone, receiving the contract could sign it, 
execute it, then do an Owner change to move the amount from 
the one-time account to his or her own account. 

First Virtual is an Internet payment system that allows 
you to circumvent sending your credit card over the 
Internet. You set up an account with them, register your 
credit card over the phone, and type in. your password when 
prompted at sites charging using this system. You have to 
• wait 60 days for your money, and it is one of the most 

barrier free- methods of receiving payment over the Internet, 
15 you do not even need a merchant credit card account to ' 

accept credit cards. You do need to set up some scripts .on a 
working First Virtual server. 
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Open Trading Protocol (OTP) is a consortium that is 
attempting to create "an open and interoperable standard for 
purchasing goods and services on the Internet." The model 
behind OTP is the existing business of purchasing goods and 
services. Existing types of participants in this model are 
explicitly identified in the model (i.e., merchant, 
7 '25 consumer, deliverer, customer care agent, bank) . 

Interoperable is a key- word here. This builds on top of 
existing payment systems to allow them to communicate. It 
does not actually do the payment or the exchange itself . as 
the present invention, SAXAS, does . OTP does not assist you 
to create and manage your own accounting units, but. if you 
did create one with SAXAS it might help you inter-relate it 
to other payment schemes. OTP derives from traditional ' 
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paperwork methods of exchanging goods and services, and is a 
protocol for presenting paperwork it builds on top of and 
assumes some payment methods . It could build on top of 
SAXAS . 

OTP assumes backend systems. for payments and record keeping. 
Account balances and • inquiries for information on previous 
transactions are not available. 

Open Financial Exchange (OFX) is a markup language for 
creating requests and formatting responses. It specifically 
tags, for USA-based financial attributes such as 401K Plans, 
etc. Security via SSL is optional . OFX does not specify how 
exchanges are processed or does it perform exchanges itself. 
OFX looks li.ke, an extended version of HTML (HyperText . Markup 
Language) with tags for specific financial structures. * It 
imposes a structure on the messages that is mapped, on the 
specific types of financial institutions that are the 
intended audience of the protocol. That is, it is not a 
generalized method for doing any value exchange. 

Instead it is a formatting standard for bank, 
transactions , wire transfers, credit card transactions, 
payments, and . investments , each of which is specifically 
identified in the protocol. For example, only certain 
country codes are recognized and they are listed in the. 
protocol definition. It is hierarchical in that clients are 
recognized by password and- servers are recognized by 
certificate. In SAXAS, by comparison, parties are ' 
symmetrical and the mechanism is general-purpose". 

In OFX, the servers are identified by X.509 
certificates. If the client and server do not share a common 
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Certificate Authority (CA) , the client cannot validate the : 
server's certificate. Therefore; OFX specifies which CAs are 
to be trusted by OFX clients. 

5 There are currently two main Certificate Authorities 

that have achieved market acceptance: Verisign and -Thawte. 
They perform due diligence on a' person of firm or- web page, 
or email address, then "certify" that the public key ' 
actually came from the entity in question, . and .generates an. 
10. X509 certificate that a party can supply to strangers to . 
vouch for them. 

SAXAS allows all parties to identify themselves with 
X.509 certificates, but such' certificates are optional in 
15 SAXAS and.it is up to a particular SAXAS server to decide 
which certificates it will, require. X509 certificates are 
not essential, to performance of the invention set forth in 
. . this application. In the SAXAS system being described 

herein, the parties to a contract may reguire a particular 
20 type of certificate from the parties, or they might . not , 
depending on the situation. 

- ' Prior Art Patents ' 

25 The prior art includes Payne et al, U.S. Patent No. 
5,715,314, issued Feb. 3, 1998, and discloses: 

A network-based sales system includes at least one . 
buyer computer for operation by a user desiring to buy 
30 a Product, at least one merchant computer, and at least 

one payment computer . The buyer computer, the merchant ... 
computer, and the payment computer are interconnected 

10 
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by a computer network. .The buyer computer is programmed 
to receive a user request for purchasing a product, and 
to cause a payment message to be sent to the payment 
computer that comprises a product identifier . 
-identifying the product. The payment computer is 
programmed to receive the payment message, to cause an 
access message to be created that comprises, the product 
identifier and an access message authenticator based on 
a cryptographic key, and to cause the access message to 
be sent to the merchant computer . The merchant computer 
. is programmed no receive the access message,, to verify 
the access message authenticator no ensure that the 
access message authenticator was created using the 
cryptographic key, and to cause the product to be sent 
to the user desiring to buy the product. 

Moreau, U.S. Patent No. 5,590,196, issued Dec . 31, 1996, 
discloses : / 

Electronic funds transfer processes are being put into 
place to replace the paper based check clearing 
process. Although ubiquitous . in the business 
environment, facsimile transmission technology has not 
been used for electronic transfer of funds. Fraud 
prevention and uncertainties in the legal status, of a 
-facsimile transmission are among the impediments for 
electronic funds transfer with facsimile. The method 
for transferring funds from, a payer to a payee 
comprises the steps- of preparing a payment form 
including information- for identifying an amount to be 
. transferred, a bank of the payee and an account number 
of the payee, receiving and verifying a security code 
• : 11 
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at an encryption 

unit to authorize a transmission including an 
encryption, preparing a facsimile transmission . device 
to send an image of the payment form, connecting the 
facsimile device through the encryption unit over a 
communication line to a payment service provider, 
receiving at the. payment service provider the 
transmission including an encryption, .and sending a - 
confirmation message t6 the facsimile device that the 
transmission has been correctly received, decrypting 
the encryption at the payment service provider, 
determining whether the encryption was authentically 
generated by the payer, extracting the- identifying 
. . • information from the facsimile transmission, and 

generating an electronic funds transfer request based 
on the identifying information provided that the 
encryption is determined to be authentic / 

Rosen, U.S. Patent. No. 5, 671,280, issued Sept. 23, 1997, 
discloses: 

A system .for electronic commercial 'payment is provided 
having a customer trusted agent .associated with a first 
money module, a merchant trusted agent that establishes 
a first cryptographically secure session with the 
customer trusted agent and associated with a. second 
money module. Where the money modules establish a 
second cryptographically secure session. The customer 
trusted agent provides remittance advice information to 
the merchant trusted agent, 'and the merchant trusted 
agent provides a commercial payment ticket to the \ 
customer trusted agent. Upon receiving said commercial 

12 
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payment ticket, the. customer trusted agent initiates a 
transfer. of electronic money from the first' money 
^module to the second money module. 

Chasek, U.S. Patent No. 5,420,405,. issued May 30., 1995., 
discloses : 

This invention describes a combination of methods and 
apparatus that creates electronic money for personal 
transactions which integrates the functions of cash, 
checks and credit cards with constant survei lance 
against fraud. This money can also serve as an 
international medium-of -exchange , and support. automated 
sales - tax . collections, and payment . This money's support 
• system is comprised of personal terminals, vendor 
terminals, an electronic banking sub-system, and 
homebase terminals. Such a system, if widely used, 
would increase commercial and personal productivity, 
provide better security against fraud and 
counterfeiting, facilitate the automation of .operations 
that involve currency, and sharply diminish the flood 
of paper that threatens, to inundate the present system. 

Micali, U.S. -Patent No. 5,629,982, issued May 13, 1997, 
discloses : ... 

A number of electronic . communications methods are 
described involving a first and second party (i.e., 
sender and recipient), with assistance from at least a 
trusted party, enabling electronic transactions in 
which the first party has a message for the second 
party. The first party, the second party and the 
"*~ 13 
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trusted party undertake an exchange of transmissions, 
such that if all transmissions reach their destinations 
the second party only receives the message if the first 
party receives at least one receipt. Preferably, the 
identity of the first party is temporarily withheld 
from the second party during the transaction. At least 
one receipt received to the first party enables the 
first party to prove the content of the message 
received by the second party. 

Elgamal, U.S. Patent No. 5,671,279, issued Sept. 23, 1997 
discloses: 



A courier electronic payment system provides customers, 
15 merchants, and- banks with a secure mechanism for using 

a public network as a platform for credit card payment 
services. The system governs the relationship between a 
Customer, Merchant, and Acquirer Gateway to perform 
credit card purchases over such networks as the 
Internet. The system uses a secure connection. to 
simplify the problem of Internet-based financial 
.transactions in accordance with an electronic payment 
protocol that secures credit card payments and 
certifies infrastructure that is required to enable all 
of the parties to participate in 
the electronic commerce, as well as to provide the 
necessary formats and interfaces between the different 
modules and systems. 

30 Gif ford, U.S. Patent 5,724,-424, issued Mar 3, 1998, 
discloses : 



14 



2 0 



.25 



WO 00/28452 



PCT/US99/25853 



Merchant computers on the network maintain databases of 
digital, advertisements that are accessed by buyer 
computers. In response. to user . inquiries , buyer 
computers retrieve and display digital advertisements 
5 from merchant computers.' A digital advertisement can 

further include a program that is interpreted by a 
buyer's computer. The buyer computers include a means 
for a user to purchase the product described. by a 
digital advertisement." If a user has not specified a 

10 means of payment at the time of purchase, it can be 

requested after a purchase transaction is initiated. A 
network payment system performs payment order 
authorization in a network with untrusted switching, 
transmission, and host- components. Payment orders are 

15 backed by accounts in an external financial system 

network," and the payment system obtains account 
authorizations from this external network in real-time. 
Payment orders are signed with authenticators that can 
be based on any combination of a secret function of the 

2 0 payment order parameters, a single-use transaction 

identifier, or a specified network address. 

Objects and Advantages 



25 Accordingly, several objects and advantages of this 

. invention . are : 

- • to be applicable to a wider range of value 

transactions, including invoicing, payments, purchase, 
sell, barter, wire transfers , market trades, 
3 0 conversions., exchanges, stock markets, purchase and 

delivery of intellectual- property such as software, 
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time limited exchange offers, deposits, withdrawals, 
and loans ; 

• to be secure enough that transactions are tamper proof 
and non-f orgeable . 

• to operate on off-the-shelf, standard, inexpensive 
computer hardware and software as well as more 
expensive proprietary systems such as mainframes. 

• to use public networks such as the Internet while still 
maintaining privacy and security. 

• to enable any organization to create their own 
Accounting Units to facilitate general or limited value - 
exchanges; examples include, but are not limited to, 
banks that require a way to manage customer balances, 
Frequent Flyer Miles for airlines, gambling tokens for 
casinos, cooperative marketing "coupons" that allow a 
customer to purchase related products from- other 
vendors , etc . 

• to facilitate the creation of public markets in these 
Accounting Units by matching buyers and sellers via 

20 automatic software . 

• to integrate easily with external applications such as 
Internet Shopping or legacy accounting systems. 

• to be independent of any specific regulatory 
environment or jurisdiction and applicable to multiple. . 

25 jurisdictions. 

■- to integrate any existing legal agreements for value 
.exchange into a computerized system for signing, 
auditing, and accounting for them. 

• to maintain account balances in a way that fraud can be 
avoided while privacy is still maintained. 

16 
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. • to be decentralized over- a wide range of servers and 

services so that there is not a -single point of failure 
that can bring down the entire system, either through 
physical failure or human intervention. .* 

• to have server functionality independent of a fixed 
network location (that is, if a server if disabled, the 
party running that server can reappear at another 
location and be recognized and in a known state 

• relative to value transactions) .. 

Other objects and advantages include: 
V to process exchanges that are not .valid until a certain 
date and time and/or which expire on a certain, date and 
t ime 

• to process partial exchanges and multiple exchanges 
over a specified period of -time at a specified limit 
price (example: between June 1 and June 6, buy 1000 
shares of Secure Accounts Ltd. at a maximum of 100 . 
Unibank credits per share). 

• to process exchanges involving unlimited numbers of 
parties as one exchange (i.e., either all exchanges 
occur or none) ; this invention makes it possible for a 
party, to act as escrow agent for an arbitrarily large 
number of parties to a single transaction. 

• to allow competing Accounting Units and exchange 
services to use the same architecture * 

•. to allow a complete audit trail of all exchanges, 
enabling account balances, to be regenerated if 
necessary due to system failure or dispute. 

• to provide non-repudiatable contracts for value 
exchanges . • . 
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• to allow a selectable degree. of confidence that you 
know who you are dealing with (the architecture allows 
any party providing a trusted service to require a 
specific type of digital signature from the parties 
that he deals with) . 

•to provide interfaces for extensibility of the 
architecture by other parties. 

• to allow private branding of value transactions by ■' 
other parties who will integrate this invention as a 
foundation for their specific exchange applications. 

• to provide simpler methods for propagation to the 
parties the final transaction documents, including 

. delivery by email or even physical mail; the underlying 
delivery model is neutral to the method employed - it 
15 need only be a one-way delivery. 

• to allow any party to nominate any trusted third party 
to be the -holder of account balances and executor of 
value exchanges. 

• the ability. to do offline transactions, such as "bank 
cheques", that will facilitate migration of store and 
forward exchange systems to fully online, systems . 

• to be technology neutral. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the invention, as 
well as other objects and further features thereof, 
reference may be had to the following detailed description 
of the invention in conjunction with the drawings wherein: 



18 



RNsnooiD: <wo nfefu.WAi i > 



AVOOO/28452 PCT/US99/25853 

Fig. 1 shows the relationship of the parties and 
resources used in a value exchange; 

Fig. 2 shows a public key .that can define and .identify 
a party and digital signature which can verify that a party 
5 agrees to the contract; 

. Fig. 3 shows an X..509 certificate that is an alternate 
way to define and identify a party, 1 / 

Fig. 4 shows an account defined by a unique triplet of. 
Holder, Owner and Backer, plus a balance; 
10 Fig. 5 shows several different types of accounts; 

.Fig. 6 shows the accounts created for one backer, two 
holders and three owners; 

Fig. 7 shows the accounts created when a holder is also 
an owner of units; 
15 Fig. 8 shows the structure of a value exchange 

contract 

Fig. 9 ■ shows the three types of contracts; 
Fig. 10 shows a Single-Party Owner Change Contract with 
' an agreement; 

2 0 Fig. 11 shows the structure of a mult i -party Owner . 

Change contract; 

Fig. 12 • shows Holder Change Contract, from' Original 
Holder to Backer;, 

Fig. 13 shows Holder Change Contract, from Backer to 

2 5 new Holder; 

Fig. 14 shows the structure of a Backer Change 
contract ; 

Fig.* 15 the same accounts in Fig. 6, but with Friendly 
Names instead of element numbers ; 

3 0 Fig. -16. shows the execution logic for an Owner Change 

contract ; 
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Fig. 17 shows the execution* logic for a Holder Change 
contract; 

Fig-. 18 shows the execution logic for a new Backer 
Change clause; 

-Fig. - 19a and 19b show examples of matching Backer 
change clauses; 

Fig: 20 shows a queue of waiting Backer change clauses 
matched to a new backer change clause; and 

Fig. 21 shows the queue of Backer' change clauses after 
matching a new clause. 

- SUMMARY OF THE INVENTION 



This invention involves a secure architecture for value 
exchanges among parties, such that the parties can be widely 
distributed geographically and can employ a wide range of 
Accounting Units. It comprises a formalized legal contract 
in a special format,' a public. key that identifies each 
party, a computer for each party, a software program for 
each party that can create, validate, sign , store , encrypt , ' 
transmit, and execute contracts, a communication method 
between the computers, and a database for each party to hold ' 
the contracts and Identity information for' each party. 
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■ ; DETAILED DESCRIPTION OF- THE PREFERRED EMBODIMENT . 

This invention discloses an architecture -for performing 
and managing value exchanges/ with an initial embodiment in 
the Secure Accounts exchange Arbitration System (also called 
SAXAS™) that operates on a wide range of inexpensive 
computer systems. 

Fig. 1 shows the main components of the SAXAS architecture 
of value exchange. An actor in an exchange is called a Party 
50. There are three roles ' that a party can play, in any given 
exchange: the Holder 58, the Owner 60, and the Backer 62. A 
party, may play more than one role in a given exchange and a." 
party's role may change for each exchange. The architecture 
allows any party to be a Backer,, a Holder or an Owner, or 
all- three: . : 

In order for a party, to exist and take part in 
exchanges ,. it must have a unique Identity 98, a computer 54, 
a database 52, and a .copy of the SAXAS software -program 56. 

The Identity 98 of a,. party consists of a unique Public 
Key 68, Fig. 2, plus any information that the party wishes 
to make public. The Identity is signed by the party. This 
digital signature ensures that the identity information does 
go with the public key. The public key is. also used to 
encrypt communications with the party ,. ensuring that only 
the- intended party can read the message. 
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The information in the Identity .includes a Notify 
Method which specifies how the SAXAS software can 
communicate with the party. This field will contain a URL 
(Universal Resource Locator ), which can specify a Internet 
address or an email address. The combination of a Public Key 
and a Notify Method creates a secure channel for notifying -. 
parties of SAXAS events that are of interest to them. - 

The identify information may also include a preferred 
friendly name, telephone number, web page address, and 
details on any SAXAS services that the party offers. ". 



The Identity may also include a list of attached 
documents,- including, but not limited to, X.509 certificates 
15 and graphic logo images. 



The computer 54 could comprise a personal computer 
(PC) running Windows® 95 or Windows® 98 with a minimum, of 
32MB of memory and at least 5MB' of free disk space to 
manage the database, code and installation requirements. 
If the computer 54 is a personal computer (PC) running • 
Windows NT Workstation or Server software, then it 
requires a minimum of 64MB of memory and 5MB of free hard 
disk space. When the JAVA program is utilized, then 
versions JRE 1.2, JDK 1.1.6, JIT 1 . 1 . 7 are involved and 
available on the Internet at http://www.java.soft.cnm . The ' 
database 52 components could include a database engine : 
compatible with JDBC, such as SQL Anywhere 5,0 from Sybase 
or Access from Microsoft. Also required is a JDBC driver 
and an ODBC drive for this "database . The SAXAS software 
.required would include an Installshield or self -extracting 
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zip file containing the SAXAS software, JRE .1.2,. JDK 
1.1.6, JIT 1.1.7. The communications requirement includes 
a TCP/IP connection to other SAXAS. sites , such as provided 
by an Internet Service Provider through a modem, or 
5 indirectly through a LAN using Network Interface Cards and 
then through an Internet Connection. 

The combination of resources belonging to a party (98, ■ 
54, 52, and 56) creates a Server 96 for the Party, which is 

10 capable of managing recording- the exchanges undertaken by 
the Party. It is possible for a single physical server to 
act as the logical server for a number of parties; the only 
requirement is that these parties share the same Transport 
public key far decoding incoming contracts. The function and 

15 use of these resources is explained further in the drawings 
and description that follow. 

The Backer 62 is the party that issues or "backs" an . 

Accounting Unit, which can also be considered as an. 
20 electronic currency or virtual currency. The backer 

guarantees the accounting unit value by providing exchange . 

to a. specified Real World value. The backer must also act as 

holder and support a market for the accounting .unit , 

matching buy and sell orders. The backer may also act as 
25 holder for' other accounting units and provide exchanges to 

and from them to his accounting unit. The backer may also- 

act as the owner of accounts with other holders. 

The Backer can be a government that . backs legal tender, a . 

bank . that backs receipts for legal tender' or for shares in a 
30 Money ' Market Mutual fund, a. casino that issues gambling 

tokens, an airline that issues frequent flyer miles, a 
. . corporation that issues phone cards, or ownership shares, or 
. *~ 23 
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coupons that can be redeemed at cooperating companies, a 
lawyer who issues units redeemable as hours. of his time, or 
any other value that someone will promise to redeem under 
certain conditions with some real world value. The 
architecture does not ensure in any way that the backers are 
reliable or can be trusted to keep their promises. What the 
architecture does do is create an open market in their 
accounting units such that the exchange value of the 
accounting units can be marked down if the backer is 
unreliable. Therefore, what is backing an accounting unit is 
actually the reputation of the backer. 



An Accounting Unit is .equivalent to the public key that 
identifies the backer 62. A specific person or organization 
15 could of course have several public keys, and act as backer 
for several Accounting Units. 

The Holder 58 is typically a bank, escrow agent or 
broker. The Holder keeps amounts for. other Owners in the 
20 Accounting Units of one or more Backers. The holder may 

provide, various exchange services that are publicly defined 
in the architecture and available for computerized 
execution. The holder must be the Owner of an account with 
each Backer whose Accounting Unit it holds. The holder may 
25 also' be an Owner of accounts with other holders and may also 
be the backer of an. accounting unit. The holder may provide 
. whatever degree, of anonymity or lack thereof that he decides 
is appropriate to his business. The Holder enforces 
knowledge of parties by requiring specific types of 
Certificates 74 in a party.' s Identity 98. 
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The Owner 60. is the signatory for one or more 
accounting unit balances at one. or more . holders . The owner 
must sign for any transfers from those balances. The owner 
may also be a holder or a backer. The owner identity may be 
5 a temporary identity . that is used only one-time.. The degree 
of anonymity allowed to an ' owner is determined by the 
holders who accept his balances. 

Fig. 2 shows the format of a public key 68 and a 

10 digital signature 114. A public key is a sequence of 
unforgeabie characters that can uniquely and securely 
identify the party who holds the corresponding private key 
(see U.S. Patent No. 4,200,770, for the Dif f ie-Hellman 
public key cryptosystem and U.S. Patent No. 4, .405, 829 for 

15 RSA public key cryptosystem). In the SAXAS architecture, 

each party is uniquely, defined by a public key. The private 
key is used to sign SAXAS contracts and changes to contracts 
that are specific to the signing party . The result is a 
digital signature 114,. like the one shown in Fig. 2. The 

20 public key is used to verify authorizations by the party, 

ensuring that only the true party can authorize withdrawals 
of- value from that .account or exchanges to other Accounting 
Units. So, the official name and identity of a Party, 
whether acting as Holder, Owner or' Backer, is the public 

2 5 key . 

Fig. 3 shows another form of party identity:, the X. 509 
. - digital certificate. This is a public key plus information 
about the real world identity of the party, all signed and 
verified by a certifying authority. .A party who acts as a . 
30 holder can require that the parties it opens accounts: for 

have valid certificates from specified authorities. In this 

' / . 25 
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way the holder can enforce the degree of anonymity it wishes 
to offer on accounts.' • 

Fig. 4 shows the structure of an account 32 in the. 
SAXAS architecture. An account is uniquely defined by the 
public key identities of a Holder 58, Owner 60, and Backer 
62, and also contains an account balance 94 in- the Backer's 
accounting unit. The same party can . appear as one, two or 
three of the Holder, Owner or Backer parties. Balances can 
be negative as in double-entry bookkeeping systems. The 
specific account diagrammed in Fig. 4 is interpreted as 
"Holder 50a owes Owner 50b the sum of -100 .units of Backer 
50c accounting units". Transferring a balance to a non- 
existent account automatically creates a new account for the 
Owner, unless this feature' is turned off by the Holder. The 
architecture makes it easy for the Holder to charge a fee 
for maintaining account records and the Holder should charge 
enough to keep account records indefinitely. 

Fig. 5 introduces the different types of . accounts that 
can.; exist in the SAXAS architecture. When the Holder and. 
the Owner are not the same .party, a positive balance 
indicates that the Holder owes the Owner the . balance amount , 
and a negative balance indicates that the Owner owes .the 
Holder the absolute value of the balance. When the Holder 
equals the Owner, the account balance indicates the total 
units owned by the Holder on his own behalf (this amount is 
zero or positive) . 

The following account balances from Fig. 5 are 
complementary and compatible.* 
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• account'- 92a has ,a positive balance and means that . 
Holder 50a owes 100 units of 50c to owner 5 0b. ' 

• account 92b has a negative balance and means . that party 
'50b is owed. 100 units of 5 0c by party 50a. When account 

92a exists' for party 50a, then account 92b -always' 
'*■ exists for party 50b. Account 92b is held by party 50b 
as a- claim against party 50a. Notice that the same 
party can be both holder and owner in different 
accounts . 

• account 92c records the total units issued to holder 
50a by backer 50c. Since the balance is negative, the 
holder'has a claim against the owner, who is also the '■ 
backer . ' ' •■ ' . 

• account 92d has the Holder and the Owner the setme party 
and a positive balance; this means that party 50b has a 
total' of 100 units of 50c that are held for it .by one . 
or more holders. Account 92b shows that the 100 units " 
are actually held by party 50a. 

An account, resides on the server 96, Fig.. 1, belonging 
to the party 50 who is the Holder specified in the account 
triplet. Therefore^ in Fig. 5", accounts 92a and 9.2c reside 
on the server of party 50a, while accounts 92b and 92d . 
-reside on the server of party 50b. . 

Fig. 5 also shows how accounts can be balanced against 
each other, both on the same server and on different 
servers . 

• Account 92a balances against 92b (that is, party 5 0a 
owes 50b 100 units, and party 50b is owed 100 units by 
52a) . 
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• Account 92c balances against 92a (i.e., the total 50c 
units issued to 50a is the suih of the units held for 
owners such as 50b) . 

Fig. 6 shows the accounts that would be created to 
handle one backer, two holders, and three owners: 

• When all three parts of the triplet are the same party 
(Holder equals Owner equals Backer), the balance 
records the total units issued by the backer to all 
parties and is negative. In Fig. 6 account 92k shows 
that backer' 50c has issued 50 units in total. 

• Accounts 92k-92m reside on the 50c server and record 
units backed by this party. Notice that accounts 921- 
92m balance to account 92k, which records the total 
obligation. Account 921 records the 2 0 units issued to 
the first holder 50a and 92m records the 30 units 
issued to the second holder 50b. Notice that the backer 
does not keep, track of which party actually owns the 
units, only who. holds them. 

• Accounts 92n-92p reside on the server of holder 50a and 
. . " balance to zero. Account 92n is the complement of 

account 921 on the backer server and records the 20 
units received .by this holder. Accounts 92o-92p record 
what happened to those 20 units: -5 units are held for 
owner 50d and 15 units for 50e. - 

• Accounts 92q-92s reside on the server of the second 
holder 50b and balance to zero. Account 92q is. the 

28 
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complement of. account 92m on the backer server and 
records the 3 0 units received by this holder. Account 
92r-92s record what happened .to those 30 units: 20 are 
held for owner 50d and 10 are held for owner 50f . 
5 Notice that party 50d has units held by both holders . 

• Accounts 92t-92v reside on the server of owner 50d and 

balance to zero. Account 92t records the 25 units total 
.• backed by 50c that belong to this owner. Account 92u 
10 records that five of the units are held by holder. 50a, 

and account 92 v records that the other 2 0 are held by 
holder 5 0b. Notice that account 92v is the complement 
of 92r and. balances it. And account 92u is the 
complement of 92o and balances it. 
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• Accounts 92w-92x reside. on the server of owner 50e and 
balance to zero . Account 92w records the total units of 
50c received by this • owner and account 9.2x balances to 
account 92p on . the holder server . 

• Accounts 92y-92z reside on the server of owner 50f .and 
balance to zero. Account 92y records the total units of 
50c received by this owner and account 92z shows that 
the units are held by holder 50b (see account 92s). 



Notice that the architecture can. balance the sum of all 
the units received by owners to the total units issued by 
the backers, irrespective of which holder is holding them 
(accounts 92y, 92w and 92t total 50 units, which balances to 
30 the -50 balance of account 32k on the backer 1 s server). 
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Fig. 7 shows how accounts are balanced when a Holder 58 
is also the. Owner 60 of some accounting units In this 
example, backer 50c has issued 50. units to Holder 50a, of 
which 5 0a holds 10 for his own account and 4 0 for Owner 5 0b. 
This is represented by the following accounts: 

• Accounts 92a-92b ' reside on the server of backer 50c and 
balance to zero. Account 92a records the total units 

. that backer 50c has issued to all parties and account 

92b records. the units issued to Holder 50a. In this 
.case they are the same, because only one holder is 
assumed. Otherwise, account 92a would balance to the 
sum total of the accounts recording units issued to any 
holder . 

• Accounts 92c-92e reside on the server of Holder 50a and 
balance to zero. Account 92c records the total units 
that backer 50c has issued to the holder 50a , . including 
both those held for owner 50b and those owned by the 
holder himself. Account 9 2d records the units actually 
owned by the Holder 50a himself (the Holder party 
equals the Owner party). Account 92e records . the units 
held, on behalf of Owner 50b. 

• Notice that account 92b on the 50c backer server also 
balances to account 92c on the holder server. That. is . 
because the units issued to 50c are always equal to. the 
units received by 50c. 

• Accounts 92f-92g reside on the server of owner 50b and 
balance to zero. Account *92f records the total. units 
backed by 5 0c that the owner 5 0b has at all holders 
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. (only one in this case) and account 92g records the 
units held for 50b at holder 92a. 



Notice that account 92e on the holder 50a server 
balances to 92g on the owner 50b server. That will 
always be the case when the Holder and .Owner parties 
are reversed in the account triplet (i.e., what you 
have sent to be held is equal to the amount that the 
holder owes you) . 
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Fig. 8 shows the structure of a value exchange contract 
66. In this architecture, all exchanges of value are enacted 
in response to signed contracts. Each of the parties who 
appears as a. source in the Clause section 82 must sign the 

15 top four sections (76, which comprises Header 78, Parties 
80, Clauses 82, Agreement 84) of the contract in the fifth 
section (Signatures 86). The contracts are signed by the 
parties using their Identity (98, either public key 68 or : 
digital certificate 74), Fig. 1, thus ensuring that everyone 

20 agrees to the same contract, then executed by .the server. 

Signatures do not oversign each other; parties sign' only the 
signable portion of the contract 76 and the Memo., Sig-Time 
and Status specific to that party in the Signatures section. 
Only a party listed in the party section. 80 of the .contract 

25 is allowed to sign in the Signatures section 86, thus. 

■ allowing verification of the signature using the public key. 

The contract resides in the data storage .of the SAXAS 
server, but can be generated in various formats for external 
3 0 use: display (HTML- format document (HyperText Markup 

Language), enabling it to be rendered via a web browser), 
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edit (also HTML) , transmission to another server (as a 
serialized object), and printing.. The format that is signed 
is a text version of the contract (not the HTML ) , which the 
software can display for user inspection and print for 
submission to a legal authority or arbitrator. 

Not all components of the contract are relevant to all 
types of contracts. The Agreement 84 is empty except in an 
owner change contract (see Fig. 9b) . The "When Contract 
Becomes Valid" field of . the Header 78 is only relevant to 
backer change contracts (see Fig. 9c); other contracts are 
valid as soon as they are signed by all parties. The "When 
Contract Expires" field is not relevant for holder change 
changes (see Fig. 9a) since they are complete as soon as-.- 
execution starts. 



Fig. 9 shows the three most common types of contracts 
in the architecture. There are different types of contracts 
with different restrictions on them in order to ensure that 
no account balances are ever lost or in an ambiguous state. 
Since an Account 92, Fig. 4, is defined by a triplet of 
Holder 58, Owner SO and Backer 62, moving an amount from one 
account balance to another can be looked at as changing the - 
associated Holder, Owner and/or Backer value. '. 

Each contract specifies an Executor 64 in the Header 
section 78, Fig. 8 . This party will also act as the Holder 
party 58 in all clauses except the destination account of 
Holder clauses 106. Each contract, regardless of type, may • 
have an optional Fee Clause 90 that is the first clause in 
the Clause section 82 . The fee clause 64 extracts a fee for 
executing the contract. If it exists, it does an Owner 
• 32 
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Change on some amount of some accounting unit from that of 
the party paying the. fee to that of the Executor. The 
accounting unit of the Fee Clause need not be the same as 
the accounting unit used in the other clauses. Therefore, 
5 there can always be one extra Backer party to the contract 
if the. Fee clause Backer differs from the others. 

There are specialized contracts in SAXAS, such as Name 
Service contracts with supply and .request identity ■ 
10 information, but these are all variations on the Owner 
Change contract, with details of the special functions 
stored in the agreement field. 

In subsequent clauses, a contract will only modify one 
15 . of the values on an account: Holder, Owner or Backer. It is 
theoretically possible to change more than one attribute of 
an account in a single contract (such as. moving an amount to 
a new owner and changing the accounting unit at the same 
. time) , but in such cases it is more difficult to ensure that 
2 0 the contract executes completely or is not executed at all 
(i.e. / that no amounts are left in limbo).- Therefore, the 
first embodiment of SAXAS does not support . that feature, in 
order to ensure reliability and easy auditing of the system, 
although other embodiments may. allow this (see Alternate 

2 5 Embodiments) . 

It is the type of. changes performed in the clauses 

section 82 that .determines the type of contract and leads to 
the three types: 

3 0 Fig. 9a: Holder change contract 98 is like a wire 

transfer; it moves a balance from one Holder to 
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another, perhaps' to then take advantage of a conversion 
service offered by that Holder>'but it does not change 
the Owner or the Backer (accounting unit).. Either the 
source or destination Holder must be the Backer, so it 
takes two contracts to move from one non-Backer Holder 
to another non-Backer Holder . The parties to the 
contract will be one Owner 60, the Backer 62 and one 
Party who is the source or destination Holder 58. There 
can only- be one Holder clause 106 in the Clauses 
section 90.. The executor 64 will be the party 
originally holding the amount,, not the destination 
party. The Agreement section 84 is empty.- The 
Signatures section 86 contains only the signature of 
the Owner; the Holder and the Backer. 

• Fig. 9b: Owner change contract 100 is like a check or 

• an invoice, depending upon . the author.. When an invoice 
is signed,., it becomes a check. The amount stays on the 
same Holder's server and in the same accounting unit, 
but has a new owner . Parties to the contract include at 
most one Holder 58 and at least one Backer 62 and at 
least two Owners .60, but it is permissible to include 
unlimited owners and backers for unlimited owner 
clauses 108. Either all the clauses are executed or 
none. The Agreement section 84 may contain one or more 
real world agreements that becomes part of the 
contract. The. Agreement is open-ended and can contain 
multiple agreements and objects. Any digital object can. 
be included in the Agreement by converting it into 
ASCII-armored format. using Radix 64 (expanding groups 

of 3 binary 8-bit bytes into 4 printable ASCII 
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.characters). The Signature section .86. must contain the 
signatures of all owners who . appear in. a source account, 
of; any clause. 

5 Fig. 9c: Backer change contract 102 is like a real 

•world currency exchange. The server matches up . the 
request to change Backer with other contracts which "go 
: the. opposite way and that have compatible prices . The 
parties to the contract include exactly one holder 58/ 
.10 exactly two backers 62 and exactly one owner 60, 

although it. is possible .that a single party could play 
multiple roles, in the contract . There .can only be one 
Backer clause 110 in. the Clauses section 90. The 
Agreement section 84 is empty. The Signatures section 
15 86 must contain the signature . of the . owner 60. 

By creating several contracts and executing them in 
sequence, it is. possible to get an amount from any account 
to the account of any Owner residing at any Holder in the 
20 Accounting Units of any Backer (assuming that there is . a 
• market being made between the starting accounting unit and 
the ending accounting unit). There are additional details 
on the structure of these three types, of contract, that are 
shown in Fig. 10-15. 
25 . • . . 

Fig.. 10 shows a simple Owner Change Contract. 100 in 
more detail . The Owner change is the simplest and most 
common type of contract. The Holder remains the same as does 
the -Backer (i.e., the Accounting Unit) . In this example,. 
30 there is only one Holder 58 who is also .the Executor 64 and 
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one Backer 62, since the fee is being paid in -the same 
Accounting Unit as the , transfer. 

However, there are two Owners 60a and 6 0b; otherwise 
5 there could be no change of Owner . All accounts must be on 
the same Holder server, which must also be the Executor. 

The only clauses allowed in the Clause section are the 
Fee Clause 90 and the Owner Clauses 108. The Fee Clause 

10 transfers 0.50 units of Backer 62 to the executor 58 in 

. return for attempting to execute the signed contract. The 
first owner clause transfers .20. 00 units of unit 62 to owner 
60b; the MinRate of 1. 00. means that the entire • amount must 
be transferred and none can be taken by the executor as a 

15 fee (for this contract, the fee is corrected by the 2.00 
units in the Fee clause). The second owner clause is a 
zero-value clause , included so that the second owner 60b 
will appear as a . debited account and will need to .sign the 
contract before it. is valid. The second signature ensures 

20 that 60b agrees with the Agreement section that follows. 

• The Agreement section spells out what' Owner 60b agrees; 
to do for 60a in return for the .20 units of 62. The 
Signature section must include signatures by 60a and 60b, 

2 5 . since both appear as owners in the source portion of 

clauses. 

Fig. 11 shows a more complex multi -party Owner change 
contract 100. Although there can only be one Holder /Executor 

3 0 in an Owner Change contract, the number of owners, backers 

and Owner clauses is unlimited/ This makes it possible to 
create multi-party swaps. None of the owner clauses will be. 
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executed unless . all' . of them are executed, i.e., if one party 
does • not have enough units to complete their part in the 
exchange, none of the exchanges occur.- 

. 5 In this example there are three owners and .three 

accounting units (backers). For purposes of example, the 
three accounting units are called by the common names 
Lumberbucks, SoftFrancs and JackpotChips and the three 
owners are called Bill, Sam and June. The contract says that 

10 Bill gives Sam 2 00 Lumberbucks, Sam gives June 500 

SoftFrancs and June gives Bill 175 JackpotChips. The 
executor/holder 58 takes 2% of each transfer as a fee for 
holding the balances and executing the trade. All amounts 
must be moved to the Executor's server before the trade. is 

15 initiated. And all three owners must sign the contract 
before, it is executable. 

• If Fig. 11 were, modified to be a. two-party Owner change 
20 instead of three parties, it would then -be similar to a 

Backer change 102.. The differences, are that in an explicit 
Backer . change the Owner does not know who . provides the other 
accounting units and may specify a limit price as opposed to 
a fixed price. So a two-party Owner change contract is like 
25 an off -market, non-anonymous block trade and the Backer 

change contract is like an automatic buy or sell order with 
• a range of amounts and prices that are possible to complete 
the • order . 

30 When a contract is being authored, signed and executed, 

it is necessary to know the Identities of each party to the 
contract. This is necessary for at least three reasons: 
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1 . to know whether we wish to deal with the party (are 
they certified by someone we trust) , 

2. to know how to communicate with the party (using their 
Public Key and Notify Method, and 

3 . to learn if a party offers the service of executing a 
particular type of contract (i.e., conversion from one 
specific accounting unit to another) . 

The party authoring a contract agrees to provide 
Identity ^ information about all the parties to the contract 
to all other parties to the contract. The author could ■ 
obtain the Identity information from web pages , email 
..messages, floppy disks, or any other medium. The method by 
which a party passes on Identity information to other 
parties is known as the SAXAS Name Service. 

The SAXAS Name Service is implemented as Owner Change 
Contracts. Any party can and will act as a SAXAS Name 
Service at various times . The party needing the Identity 
information authors a contract requesting Name Service on a 
specific Public Key; these details are stored in the 
agreement section of the contract. The contract is sent to 
the Name Service party for execution. The Name Service 
inserts the desired Identity into the memo field and signs 
it. Any party can also pass their own Identity on to other 
parties by including it in their memo section. of any' 
contract and signing it. 

Fig. 12 shows a Holder- Change Contract 98 in more 
detail. There are two basic formats: from a Holder to the 
Backer, or vice versa. This is an example of the first 
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format: move 400 units backed by party 6 2 and owned by party 
60 from holder 58 to backer 62 . A fee. clause is used to 
collect 1.15 units of 62 for performing the transfer. The 
Backer is always the Executor of holder change contracts and 
5 always receives the fee, if any. The Agreement section is 
empty. The Signature section requires the signature of the 
Holder 58, Owner 60 and Backer 62 . 

Fig 13 shows a Holder, change contract' 98 that goes from 
10 the backer to a holder. In this example, the Backer 62 is 

acting as the original Holder as well. The amount is moved, 
to the party 58 as the new Holder. The Fee clause allows the 
executor, who is the backer in this case, to take up to 0.75 
units and move, it to the account described as 62-62-62 in . 
15 HOB format (this is account 92k on Fig. 6, the same account 
that usually. has a negative total for all the units issued 
by this backer. So in effect the backer is withdrawing some 
units from circulation by collecting this fee r 

20 The holder clause transfers 400 units from the backer's 

server 62 to the server of party 58, making 58 the new 
holder. There can only be one holder clause per holder 
contract. This clause also allows the executor to take up to 
0.2% of the amount as a fee.. When a Holder to Holder change 

25 is executed as two contracts and uses the Backer as an 

intermediary, there is no information left on the original 
Holder as to the final destination of the amount.' Only the_ . 
Owner and the Backer . know that the. funds moved from Holder A 
to . Holder B. 

30 " • . • . 

Fig. 14 shows the Backer Change Contract 102 in more 
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detail. In this case, the Fee clause is in a different 
accounting unit from either of the units involved in the 
Backer Clause itself . This is permissible under the SAXAS 
architecture. The Backer clause 110 offers to give up 40 0 
5 units backed by 60b in return for some units, backed by 60c 
as long as the conversion MinRate is 0.552 or better. When 
the actual conversion is performed, the owner 60 will not 
be aware of who traded him the units. The executor matches 
up this contract with complementary contracts that offer . 
10. to go the other way and also match . in price . The actual 

conversion rate will, be based on. the offers "available and 
a fee charged by the executor for this clause. . 

SAXAS allows for a single conversion clause to remain 
open and be matched up with multiple - complimentary 

15 conversion clauses created by other owners. The clause 
will remain active and available for matching until the 
full amount offered for conversion has been converted, or 
the owner is found to have insufficient funds in his 
. account, or the expiration date occurs . The details of 

2 0 each partial conversion are stored in the executor ' s memo . 
field of the contract, and re-signed by the executed. after 
each partial; conversion. See Fig. 18-21 for operational; 
details . 

Operation of the SAXAS System. Figures 15-21 

■ 25 

.Each SAXAS account is uniquely defined by an identity, 
triplet: Holder, Owner and Backer. It' is possible for each 
component of the triplet to be a different party, the same 
party, or a mixture of parties. 
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The Holder is the party where the account . resides . The 
Owner is the party who signs for the units and. controls the 
account. And the Backer is the party who defines the 
accounting unit for the. account and "backs it" .' Every party 
in the system has a SAXAS account server and thus has 
accounts where it is the "holder" , although these may exist . 
only to balance with accounts that the party has with other 
parties. 

Contracts all have an ."Executor" that signs that a 
contract has been executed so that other parties to the 
contract know to update their books on notification. The 
executor is the final authority, or "commit coordinator" . 
In the case .of, owner change or backer change contracts it is 
the holder of the account. In the case of holder change 
contracts it is the backer of the currency, or central bank 
for that currency. 

The executor does not execute a contract unless all 
owners of accounts giving up something (and' an owner change 
can have, more than one) . have signed. Also, in a holder 
change the holder's have to sign. The holder where the units 
are going to has to agree to hold ..the units. The holder 
where the units are coming from has to agree that the owner 
really had that much. 

Fig/ 15 shows the same sample set 'of accounts as in 
Fig. 6, but in this case the element numbers have been 
replaced with friendly names to make the logic easier- to 
follow.. Assume that the friendly name of the' party backing 
the accounting unit is 
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$-Backer, the names, of the parties acting as holders" are H- 
Bank and Union Bank, and the names of the parties acting as 
Owners are Bob, Alice and Ted . Each Party has some ' Accounts 
on their server and some accounts on other servers, as shown 
5 in Fig. 6. It" is noted that any accounts residing on a 

party's server will have that party. as the "Holder" of the 
account, even though that party is acting as an Owner in the 
overall SAXAS scheme. 

10 

Owner Change . 

Fig. 16 shows the execution of an owner change 
contract. See Fig. 10-11 for the structure of an owner* 
15 change . . ■ ' , 

Processing is simplified because the owners must move , 
all amounts to be swapped onto the Executor ' s- server. No 
other servers are communicated with in the execution of a 
contract, although the server does send a notification copy 
of the completed contract to each party s,o. that they can 
update their book keeping. 

The optional fee clause is .handled separately from '. the 
other ' owner change clauses. It . is executed as soon as . the 
executor receives a copy that is signed by the author and 
the. fee payor,, "regardless of whether all the clauses of the' 
contract turn out to be executable or not. 

The executor verifies that any parties appearing as 
"debited owners" in the contract have properly signed the 
contract. Execution of an Owner Change is done as a unit, 
regardless of how many clauses and owners are involved. The 
• 42 
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Executor logically, executes , all clauses simultaneously. This 
is done by locking all the balances in the database, 
executing all the transfers, then canceling the entire 
operation if any. of the accounts falls below the required 
5 Minimum Balance (usually 0.00 or the largest negative 
number ). , 

This execution model means that you can exchange 
something in an Owner change that you .do not own at the 

10 start of the execution, but acquire during execution of the 
clauses. The Executor computes any percentage fees to be 
charged on each clause, but does not actually credit them 
until the end. Otherwise the Executor would have to lock the 
Executor's account for the entire execution time of the 

15 contract and this would make the process inherently single 
threaded, since the Executor is involved in every contract' 
on the server. ^ 

As a final step, the Executor attempts to send a 
2 0 notification copy of the contract as executed to each party. 
This, may involve use of the SAXAS Name Information Service 
to discover where the parties are currently to be notified. 
Notification can be via email. if a party is. not currently 
online,, or notification may be optional. 

25 . 

Returning to Fig. 15 with the friendly names, assume 
that there is a SAXAS Owner Change contract (as in Fig. 10 
and 16) with a clause transferring $3 from Bob to Alice, the 
contract executing on the H-Bank server where they both have 
30 accounts. Since each account is an (HOB) "triplet", the 
overall transfer as executed by the H-Bank server can be 
summarized as 
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(H-Bank, Bob, $) $3-> (H-Bank, Alice, $ ) 

So on the .executor server (H-Bank) there are 2 accounts 
5 updated: 



( H-Bank, Bob, $) -$3 H-Bank is holding 3 less for Bob 
,( H-Bank, Alice, $) +$3 H-Bank is holding 3 more for Alice 



10 



15 



20 



However, to keep the entire SAXAS system in balance,, 
there are other accounts that must, be changed as well. 
Starting with the H-Bank server, when it executes the . 
contract, it updates the two accounts mentioned above. Then 
it sends a notification copy of the contract to Bob and to 
Alice, whose SAXAS servers must also update accounts that 
they hold : 



On Bob's Server: 
(Bob, Bob, $) $25 - $3 = $22 Total $ held by Bob 

anywhere 

(Bob, H-Bank, $). -$5 + $3 = -$2 $ held by H-Bank for Bob 

On Alice ' s Server: 
(Alice, Alice, $) $15 + $3 = $18 Total $ held by Alice 
anywhere 

(Alice, H-Bank, $) -$15-$3 = -$18 $ held by H-Bank for Alice 



3.0 Holder Change 

Fig. 17 shows execution of a Holder Change Contract. 
See also Fig. 12-13 for the structure of Holder . Changes . 
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A Holder Change Contract is like a wire transfer in the 
traditional world of financial transactions - an amount is 
moved from one Holder to another, but retains the same Owner 
and Accounting Unit • (i.e. Backer) . 

•The receiving, holder- has to agree (sign) to hold, the . 
units before the contract is executed. .This allows a ; 
holder control over whom it holds units for by automatically 
verifying that the party's Identity contains certain 
"certificates". It also makes the holder promise that he is 
just holding the units and that it is really still the 
owners . 

An. honest holder will' have enough, units- on. record with- 
the Backer to be able to cover all of the. owners he is 
holding for; When units leaves one holder the Backer for 
that currency will. refuse a contract if the holder does not 
have the units to cover it. A backer is like a central .bank 
for clearing inter-holder transfers in his currency. And 
acting as the . central bank., for his currency, the backer is. 
the executor for all holder changes in his currency. 

There are three cases, of holder change, although the first 
two are a. necessary and sufficient core. The third is ,an 
alternate embodiment of the method. 

1) You can transfer from a holder, to the backer 
.2) From the backer to some holder 
3 ) From one holder to another where neither is the backer 
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15 



30 



Case 1:- The sequence of events when going from a holder to 
the backer is: / 

1) . Owner signs holder change contract 

2) Backer signs indicating "agree to hold for this owner" 

3) The old holder . .- ' 

A) Verifies that the owner has the units 

B) Updates his books and signs (he expects Backer to 
execute) 

C) Sends copy to both the backer and the owner 

4) The backer executes the .contract, updating his books , 
and change the contract, status to "executed" 

5) Backer notifies owner and old holder that contract is 
executed- * 



Case2 : The sequence of events going from the Backer to 
another holder is: 

• 1) Owner signs holder change contract 

.2) Destination holder signs indicating "agree to hold 
2 0" for this owner" 

3) The backer signs .and executes after checking the 
. balance 

4) The backer notifies owner and new holder that , the 
contract is "executed" and they then update their 

25 books 

Case 3: Moving from holder A to holder B where neither is. 
the. backer (see Alternate Embodiments later in this 
. document) 



If an owner were moving units from one server to 
another, there is the danger that the first server had 
updated his books, but the new server did not receive the 
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notification and thus had not credited the owner with the 
units in his books. To correct this invalid . si tuat ion , the 
owner would send the new holder another copy of the 
contract; if the. contract is valid and. has not been 
processed on the destination server yet, the server will 
update its books to credit the owner with. units. * 

The Holder Change contract allows the Owner to move 
value amounts from one Holder to another, but without 
changing the Accounting Unit (Backer). The contract is 
signed by the Owner, the Holder and the Backer, to ensure 
that the amount will not be rejected when it arrives, at its' 
destination. The author will create two contracts , one to 
move the amount from the current holder to the backer and 
the second to move it on to the new holder. The reason for 
this is that it makes each contract atomic and unambiguous. 
The owner can always verify where, the funds are - they are 
never in limbo. If the funds. get to the backer, but cannot 
be transferred to the new holder, they' are- still in the name 
of the owner on the backer's server and . the owner can verify 
their status. 

An Example with 2 Holder Change Contracts 

Returning, to Fig. 16 with the friendly names, assume 
that two SAXAS holder change contracts are created, with the 
first transferring the amount to the Backer and the second 
transferring it to the final destination Holder. In both 
cases owners creates the contracts and the $-backer is the 
"executor" . 
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Going back to the original -state of accounts in Fig . 
6a, assume that Bob wants to move $5 from Union Bank to Pi- 
Bank. That can be represented in (HOB) triplet notation as 
these two transfers: 

5 

Contract 1: (Union , Bob,. $ ) $5 , •. ($,Bob,$) . 

Contract . 2: ($,Bob,$) $5 -» (H-Bank, Bob/$) 

Contract 1: Holder to Backer 

10 " " ~ ~ ~ ™ " ~~ "~ • • . : 

This " (Union, Bob, $) $5 -» ($, Bob, $.)" ' contract is NOT 
executed on the Union Bank server because it will be 
executed on the $-Backer . server . However, Union Bank must 
both ensure that Bob has sufficient funds and ensure that he 

15 does not spend' those' funds once the transaction is 

committed. 5 The S-Backer server must verify that Union has ... 
enough total funds to perform the transfer (although the 
Backer does not know if Bob has enough funds) . So both 
servers have to sign off on sufficient funds. 

. The way this is handled in SAXAS is that the . original 
holder "tentatively transfers" the funds out . of Bob's 
account and into the Backer's account in anticipation of the 
contract execution. This' is a reasonable expectation because" 

2 5 the executor-Backer has already signed the contract saying. 

that he -will perform it once the holder signs it. If for 
some reason the contract does NOT go through to execution, 
the holder will received as negative notification from the 
executor and must be prepared to move the funds back to 

3 0 Bob's account. 

Tentative Transfers On the Union Server: 
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(Union, $,$) -$30 + $5 = -$25 Total .$ held by Union 

. Bank.. 

(Union, Bob$) $20 - $5 = $15 $ ,held £ or . Bob by Union 

Bank 

5 

Then the Union Bank server sends a. notification copy to 
$ -Backer and to Bob. 

On the $ -Backer Server: 
10 ($ / Bob l $) $0 + $5 = $5 Open account for Bob, 

deposit $5 

($, Union, $) $30 - $5 = $25 Reduce $ holdings of Union 

Bank 

15 On Bob's Server: 

(Bob, Union, $)" -$20 + $5 = -$15 Reduce $ held at Union 

Bank 

(Bob,$,$) $0 - $5 = -$5 $ -Backer now owes Bob $5 

20 The executor also sends a notification copy to Union, 

the original holder. However, since it has already does the 
transfers in anticipation of this notification, it merely 
marks- the contract as complete. 

25 Contract 2 : Backer to Holder 

The $5 is now at- the Backer's server. A. second contract 
• is executed to transfer it to H-Bank, still in the name of 
Owner Bob: ■' ($,Bob,$) $5 -> (H-Bank, Bob, $) " 



3 0 



On the $-Backer. Server : 
($ , Bob, $) $5 - $5 = $0 Close out Bob, withdraw 
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($,H-Bank,$) $20 + $5 = $25 Increase $' holdings of H- 

Bank 

Then $ -Backer sends notification copies of the signed 
5 contract to H-Bank and to the Owner Bob, so that there book 
entries can be updated as well. Here are the transfers on 
each server : . 

On H-Banks Server: 
(H-Bank,$,$) -$2 0 - $5 = -$25 Total $ held by H-Bank. 
10 (H-Bank, Bob, $) $5 + . $5 = $10 Bob $ at H-Bank up by $5 



On Bob ' s Server : 
(Bob, H-Bank, $) -$5 - $5 = -$10 Increase $ owed Bob by H- 
15 Bank 

(Bob,$,$) , -$5 + $5 = $0 Close out temp account at $- 
Backer 



20 



25 



30 



Backer Change 

The Backer Change Contract is a conversion of 
accounting units . The Owner and the Holder remain the same 



Fig. 18 shows execution of a Backer Change clause in a 
^.-Sr-r ■ Backer Change Contract (see Fig, .14 for the structure) . As 
with other contracts, the fee clause is executed at once 
when the contract is recorded by the Executor. There may 
also be percentage fees extracted from each conversion. The 
Executor can be any holder that makes a market. The 
conversion fees charged by that Executor are described in 
their identity record. 
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Each backer change clause of the contract is executed 
independently. Although the Backer change contract as 
described statically in Fig. 15 appears to involve only the 
Holder and the Owner. In fact the Holder matches the ' 
5 contract with one or more reciprocal contracts by other : 
Owners/ contracts which offer the reverse conversion at : a 
MinRate which allows matching of the contracts.- 

Each clause has a MinRate value, which is the minimum . 

10 rate at which the conversion can occur. On the initial 

execution of a new Backer Change clause, the actual rate at 
which it- occurs is higher than MinRate, if the Executor can 
find a matching contract going the other way that allows for 
.the/ Executor ' s fee. Partial conversion is supported, as well 

15 as conversions by matching multiple reciprocal contracts. 

After the initial execution, if there is any amount 
left to be converted, the contract goes into the outstanding 
offers list. If the contract is matched with a new incoming 
2 0 contract before it expires, it receives exactly the MinRate. 

The Backer Change Contract cannot be ' shown using Fig. 
15, since Fig. 15 only shows one Backer for all amounts. 
Therefore, go back to the initial state of Fig. 15 and 
25 assume a new party Y acting as Backer for a new accounting 
unit, CyberYen. -Y authorizes Union Bank to hold accounts, 
backed by Y and Union Bank offers a service converting- Y 
units into $ units and vice versa, all performed by the_ 
SAXAS server. 
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If Owner Ted wants to convert $5 from his Union Bank 
account into Y at a minimum rate of 100Y per $, this can be 
notated as a Backer Change Offer in SAXAS : 

(Union, Ted, $ ) $5 @10 -> (Union , Ted, Y) 

If the Union SAXAS server can complete this Backer 
Change and sends the notification copy to Ted, the following 
transfers occur: 

On Union Server 
(Union, Ted, $) $10 - $5 = $5 -Extract $5 from Ted's 

. account . 

(Union, Ted, Y) Y0 + Y500 = Y500 Credit new Y account for 

Ted . . 

On Ted ' s Server 
(Ted, Ted, $) "$10 - $5 = $5 Reduce, total $ owned by Ted 
(Ted,Union, $ ) -$10+$5 = -$5 Reduce; $ owed by Union to Ted 
(Ted,Ted,Y) Y0 . + Y50.0 = Y500 Total Y units owned by 
Ted 

(Ted,U,Y) -Y0 - Y500 .= -Y500 Y units owed to Ted . by. 
Union 

However, where did the Y500 come from and where did the 
$5 go to? This -Backer Change can only occur if there is 
someone else with a contract on the Union server offering to 
convert. 500Y to $ at a rate of 0.01Y per $. Assume that 
Bill is a party with Y1000 and $0 and the f oil owing • SAXAS 
contract offer; Then the Union server can match up Bill's 
contract with Ted's contract and make the conversion: 
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(Union, Bill, Y) Y500 ©0.01 -> (Union , Bill :,$ ) 

On Union Server 
(Union, Bill , Y) Y1000-Y500=Y500 Extract Y500 from Bill's. 
5 acct 

(Union, Bill ,$ ) $0 + $5 = $5 Credit new account $5 for 
Bill 



10 



On Bill 's Server 



(Bill, Bill, Y) Y1000-Y500=Y500 Reduce total Y- owned by 
Bill 

(Bill, Union, Y) -Y1000+Y500=-Y500 Adjust Bill's Y. at Union 

(Bill, Bill., $) $0 + $5 = $5 Total. $ owned by Bill 

15 (Bill, Union, $) $0 - $5 = -$5 $ owed by Union to Bill 

As a result of these Backer Changes, the total Y and $ 
held by Union Bank has not changed, but they are allocated 
to different Owner accounts. In order for the . Union server 
20 to stay in balance, both of these Backer Changes must be 
executed at the same time as a single unit, even though 
there are two contracts. . 

Fig. 19a shows an example of two reciprocal backer. 
25 change clauses that will be matched and. executed. Below are 
two contracts that can be matched up and executed, • if the 
fee. .is zero. Assume Holder A, Owners B and C, Backers D and 
E: 

3 0 ABD => ABE 100 @ MinRate 0.5 {100D * 0.5 = 50 E) 

ACE => ACD 100 @ MinRate 2.0 (50E * 2.0 = 100 D) 
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This is interpreted as "Owner B offers to exchange up 
to 100* units of D for .0.50 units of E per D, or better. And 
Owner C offers to exchange up to 50 units of D, the price 
being 2.0 E per D or less". The executor can match these two 
contracts, exchanging 50 units of E from owner C for 100 
units of D from owner B. 

In the example of Fig. 19a, the reciprocal backer 
clauses are at exactly the same price. This does not leave 
any spread for the executor to take a fee. 

Fig. 19b shows a different situation where there is a 
spread, between the bid and offer.. 

ABD => ABE 100 @ MinRate 0 . 48 100D * 0.48 = 48 E • 
ACE => ACD 100 @ MinRate 2.00 50E * 2 . 00 = 100 D 

The Fig. T9b example is the same as Fig. 19a, except 
that owner B has lowered his price . He ' will part with 100 D 
units for 48 E units instead of 50 E. Since owner C will 
give up 50 E units for 100 D, there are 2.0 units of E left 
over, from which the executor can extract his fee. 

Assume that the executor fee in Fig. 19b is only 1.0 E. 
The remaining 1 . 0E of spread goes to the new contract. If we 
assume that B*s contract is new and C ' s is already in the 
system waiting for new offers, B- would get 49E.for 100D 
instead of 48E. 

The fee that the Executor will charge must be stored in the 
database somewhere so the software can match the trades 
automatically. They are available to the outside world via a 
Name .Service request. 
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Fig. 20-21 shows waiting bids and offers and how they 
are. matched with a new, incoming contract. Note that none of 
the existing Backer change clauses can be matched because 
5 the sellers are asking more than the buyers are willing to 
pay. So the clauses wait on the Holder's server for a new 
Backer change clause to appear. 

If the new contract falls in the price gap between the 
10 unmatched clauses, it will be matched with one or more of 
them. 

The- new. offer to sell 60 units of D at a MinRate of. 
4.25 E per D- can be matched with the two best offers to sell 
15 D for E . 

The best waiting offer is to sell 50E at 4.40 E per D, which 
equals 11.37D, plus a 1% commission of 0.1137D, gives a 
price of.ll.4837D. 

20 • 11.37D goes to the party selling the 50E. 

• 50E goes into the account of the new contract. 

• 0.1137D goes to the executor. 

• 11.4837D comes out of the account of the new contract . 
This leaves an outstanding new contract to sell. 

25 • 48.5163D at 4.25E or better. 

• The effective rate on. this exchange was 4.35 E per D to 
the new contract, or better than the offer of 4.25, 

The second best waiting offer is to sell 137E at 4.30 E 
3 0 per D, which matches the amount remaining on the new 
contract. Therefore this order is matched as well, 
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generating a. price of 31.86D plus a 1% -commission of 
0.3186D, which equals 32.1786D. 

• 31.86D goes to the party selling the 137E. 

• 137E goes into the account of the new contract. 

• 0.3186D goes to the Executor. 

• 32.17 86D comes from the account of the new contract. 

• The effective rate for this exchange is 4.257, which is 
better than .4.25. 

• There is still an outstanding offer to sell 16.3377D at 
4.25 E per D, but there are no more waiting offers to 
match . 

Therefore, the outstanding balance goes into the list 
of buy and sell orders as the best unmatched sell offer'.. It 
will be matched with the- first new contract that comes in 
and offers 4.25. The new contract gets the benefit of the 
best price. The, old contracts that are waiting on the server 
for . further matches . will always get their MinRate and .no • 
better, but they don't have to pay any fees. The new 
contract effectively pays the Executor's. fee if. there is 
one . 

Fig. 21 shows the resulting buy and sell orders after. ' 
the new contract is processed. Notice the two offers to 
sell E for D are gone, and new offer to sell D for E has been 
added. 
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Alternative Embodiments 
Alternative Execution Models 

In. the preferred embodiment, a clause in a SAXAS 
5 contract . changes only one element of the Identity triplet 
defining an account: either the holder, the owner, or the 
backer. This simplifies the design and the implementation 
and makes it less likely that any units will ever be lost. 
It is also, desirable to change two of the elements in a • 
10 single clause. 

Since any * arbitrarily complex transfer can be 
accomplished with combinations of contracts/ other 
embodiments of the SAXAS user interface can allow an owner 
15 ■ to transfer an amount from any currency, any place, to any 
other, owner in any other currency at any other place, using 
the contracts, in the preferred embodiment . 

Also, the holder change can be performed in a single 
20 contract instead of . two contracts (holder to backer and 

backer to. holder) . The logic is similar to the. two contract 
method," but occurs as a single logical step: 

1) Owner signs holder change contract - 

2) Holder B agrees. to hold for that owner 

3) Backer, agrees to hold for the holder B 

4) . Holder A checks : that owner has the funds and updates 
his ' books 

5) Backer checks that holder A has funds, updates books 
and marks contract as .-"executed" and notifies owner, B,. 
and A 
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6) Owner, and holder B update their books 

The Backer is the executor of Holder Change contracts, 
because the Backer is the only one who can give any 
assurance that the holder still has the amount' that is being 
transferred. Actually,- the Backer can only verify that the 
holder has at least the amount in the contract in total 
funds;' the' Backer cannot verify that the holder has not done 
something amiss with other amounts . 

Alternate Software Methods 

The preferred embodiment of this invention was written 
in the Java language , but there is no reason why it could 
not be rewritten in C, C++, COBOL, FORTRAN, Pascal, 
CodeWarrior for the Palm Pilot, or any other computer 
language. 

. Alternate Data Store Methods ' 
The preferred embodiment of this invention used the 
JDBC (Java Database Connectivity) interface to databases, 
but the invention could be implemented with any database ., 
interface that supports tables and transaction commit, 
including but not limited to DB-2, Oracle, Sybase, Mini-SQL. 

Alternate Packaging 
The preferred embodiment of this invention is a 
standalone program that performs its own communication and 
display, but it could also be embodied as a browser plug in. 
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Alternate Computing Devices 

The preferred embodiment of this invention is an Intel- 
Microsoft personal computer,- but the invention can be easily 
implemented on a wide range of computing platforms, 
5 including but not limited to UNIX, IBM AS/400 , • Hewlett- 
Packard MPE/iX, DEC VAX , and IBM mainframe.- . A database is 
not needed; only a way to store and recall- contracts . A 
network connection is not needed, only a way to send a 
contract from one party to another.. The contract could, even 
10 be printed, mailed, scanned, converted back to characters by 
optical character recognition, and it would still be valid. 

A computer is not strictly needed, only an algori thinic 
device "that "can parse the contract, compute the mathematical 
15 signatures, and send the contract on in some fashion. Given 
advances in various technologies, this could be a 
specialized piece of hardware or a genetically engineered 
biological entity. 

20 • While the invention has been described, with reference 

to specific embodiments, it .will be. understood by those 
skilled in the art that various changes may be made and. . 
equivalents may be substituted for elements thereof without 
departing from the true spirit and scope of the invention. 

25 In addition, modifications may be made without departing 
from the essential teachings of the invention. 

We claim : 
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1. A method for exchanging ownership of values among two 
or more parties, comprising the steps of 

providing, a computing device as a means to" input, 
output and store information and perform mathematical and 
5 logical algorithms on said information, 

providing a secure channel for sending information 
intended for a specific party from said computing device to 
another computing device, and 

providing a computer program to control said computing 
10 device, said computer program being capable of: 

operating on several computing devices under control of 
native parties that control the computing device, 

creating a digital identity for said party, said • 
digital identity comprising a unique, verifiable sequence of 
15 bits that can create a digital signature for a specific 
digital document and a . plurality of optional attributes , 
said optional attributes comprising the specific secure 
channel to be used in sending information to the party, the 
real: world identity of the party, and the exchange services 

2 0 provided by. the party, 

receiving said identities when sent 1 over said secure 
. channel , 

creating an accounting unit for said value, such 
accounting unit being divisible into fractional parts, being 
25 transferable, and. being defined by a backer party who 

defines terms under which said accounting unit may' be '-. 
surrendered for said value, 

receiving information regarding said accounting units 
when sent over said secure channel, 

3 0. creating accounts, said accounts to contain a balance 

amount, said balance amount to be recorded in one of said 
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accounting units, controlled by. a owner party, and entrusted 
to a holder party, and . 

creating a contract in digital form. 

1 2. The method for exchanging' ownership of values among two 

2 or more parties as set forth. in Claim 1 , further . including 

3 receiving said contracts when sent over . said secure 

4 channel, and 

5 , sending said contracts over said secure channel to 

6 parties on . other said computing devices. 

3. .The method for exchanging ownership of values among two 
or more parties as set forth in Claim 2, further including 

signing- said contract using said digital identity of a 
party native to said computing device, 
5 verifying that said contract is validly signed by the 

digital identities that are named as parties in said 
contract , 

executing said exchange clauses in said contracts when 
said contracts are validly signed by all impacted parties 
10 and when the designated executor . party is native to said 
computing device.. 

4 . The method for exchanging ownership of values 
among two or more. . parties as- set forth in Claim 3, wherein- 
said, step of executing comprises the steps of 

moving accounting units from one owner party to another . 
5 owner party, 

converting amounts from, one" accounting unit to another., 
accounting unit, *-.■*■ 
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matching and executing reciprocal buy and sell 
contracts, transferring amounts from one holder party to 
another holder party via the control of the backer party, 

adjusting account balances in . a double-entry manner so 
that they balance to zero in total, 

optionally processing said textual agreement, causing 
information on said parties, said accounts, or said 
contracts to be appended to the' contract and signed by the 
executor, 

notifying all parties to the contract by sending a copy 
over said secure channel, and . 

optionally signalling software programs external to the 
method that said contract has been executed. 

5. The method for exchanging ownership of values among two 
or more parties as set forth" in Claim 4, wherein said . 
contract comprises* 

a header, said header comprising the author party and 
executor party and contract type, said contract types 
specifying special interpretation of the text agreement , 

a list of party identities , 

a list of exchange clauses, 

said text agreement comprising a legal agreement among 
the parties and, optionally, directions to be interpreted by 
the software program for specific contract types, and 
. a list of digital signatures by said parties. 

6. The. method for exchanging ownership of values among two 

or more parties as set forth in Claim 5 further including ■ 

creating said exchange clauses, said exchange clauses 
comprising 
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5 a route for the value exchange., said route comprising a 

from account and a to account, 
an amount, 

a debit amount indicator if said amount is to be 
removed from said from account or a credit amount indicator 
10 if said amount is to be added to said to account, 
a minimum conversion rate, and 

a mortality field to determine how long the clause 
should remain executable. 

7. A secure architecture for performing and managing value 

exchanges among parties comprising: 

a formalized legal contract in a special format, 
a public key that identifies each party to the value 
5 exchange, 

a software program for use on a programmable computer, 
for each party that can create, validate, sign, store, 
encrypt, transmit, and execute contracts, 

a communication link between said computers for 
10 transmitting .the value exchange information, and 

a database for each party to hold the contracts and 
identify information for each party \ 

1 8. • The secure. architecture of Claim 7 wherein said public 

2 key is also used to encrypt the transmitted value exchange 

3 information to ensure that only the intended party can read 

4 the message transmitted. 

1 9. The secure architecture of Claim 8 wherein each party. 

2 is identified by a unique identity,' said identity including 

3 said public key. 
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10. The secure architecture of Claim 9 wherein said unique 
identity includes at least one of a party's preferred name, 
telephone number , Internet web page address, and system 
services offered. 

11. The secure architecture of Claim 7 further including a 
personal computer upon which said software program is 
installed . 

12. The. secure architecture of Claim 11 wherein said 
personal computer ' s operating system is Windows 95 or ' 
Windows 98 . 

13. The secure architecture of Claim 12 wherein said 
operating system also- include the JAVA program. 

14. The secure architecture of Claim 7 wherein said public 
key comprises a sequence of unforgeable characters that 
uniquely and securely identify a particular party. 

15. The secure architecture of Claim 14 wherein said public 
key further includes a digital certificate, said certificate 
comprising the real world identity of a particular party, 
signed and verified by a certifying authority. 

16. The secure architecture of Claim 7 wherein each party 
to. the transaction has an account/said account comprising 
the identities of. the" parties ,' said parties including at 
least a Holder/an Owner, and a Backer . 

17. The secure architecture of Claim 16, wherein a Holder 
is one of a^bank, an escrow agent, or a broker. 
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1 18. The secure architecture of Claim 16, wherein an Owner 

2 is the signatory for one or more accounting unit balances, 

3 said accounting unit comprising one of any legal tender, or 

4 other, unit of value for which one party, would promise to 

5 redeem in return 'for something with a real world value. 

1 19. The secure architecture of Claim 16, wherein a Backer 

2 is that party to the transaction that issues an accounting. 

3 unit, said accounting unit comprising one of any legal 

4 tender, or other unit of. value for which one party would 

5 promise to redeem in return for something with a real world 

6 value . 

20. The secure architecture of Claim 7, wherein said 
formalized contract comprises at least four electrically 
signed sections, said sections comprising 

a header section which includes at least one of a 
5' title, author, executor, date of contract maturity , 

a parties section which includes the identification of 
the party, . 

a clauses, section which includes the amount of the . 
contract and the interest rate, 
10 an agreement section which includes the . actual text of 

. the contract agreement . ■ 

1 21. The secure . architecture of Claim 20, further including 

2 a fifth section, said section comprising the electronic 

3 signatures of all. the parties to the contract. 
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22 . The secure architecture of Claim 12 wherein said 
operating system also includes at least one of the followinc 
programs: C, C++, COBOL, FORTRAN, . Pascal , CodeWarrior. 

23. The secure architecture of Claim 7 further including a 
database interface, said database interface including at 
least one of DB-2 , Oracle, Sybase, Mini-SQL. 

24. The secure architecture of Claim 11 wherein said • 
personal computer is one of ■ the following computers : Intel- 
Microsoft family of computers, UNIX, IBM AS/4 00, Hewlett- 
Packard MPE/iX, DEC VAX, IBM mainframe. 
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